All responses are 200 (server error)

All responses are 200 (server error)

am 27.09.2010 11:27:33 von Nico Coetzee

--0015175cb1d4926c0804913a5617
Content-Type: text/plain; charset=ISO-8859-1

Hi - don't know if anybody else have come across this.

I have a mod_perl instance that produces output just as it should (checked
in the logs and I even written the output to file just to have an extra
check).

The tcpdump also show everything is ok.

BUT

The content has the following HTML appended at the end:



200 OK

OK


The server encountered an internal error or
misconfiguration and was unable to complete
your request.


Please contact the server administrator,
webmaster@host.example.com and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.


More information about this error may be available
in the server error log.



Apache/2.2.3 (CentOS) Server at webdavtest Port 81



So, I've enabled "debug" level logging everywhere and even enabled
diagnostics in the mod_perl script. Nothing strange shows up anywhere.

I even tried to change the return code with return Apache2::Const::XXX (XXX
could be anything) but the return code is ALWAYS 200 with the above HTML
appended to what ever output is sent to the browser.

I also noted that the content length header is correct for the content sent
to the browser and does not include the additional HTML above, but it still
confuses the browser.

Any ideas?

Environment:

CentOS 5.5 OS with the following packages:

* httpd-2.2.3-43.el5.centos.3
* mod_perl-2.0.4-6.el5

In my config I have the following enabled:

* LogLevel debug
* PerlWarn On

Thanks

Nico

--0015175cb1d4926c0804913a5617
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi - don't know if anybody else have come=A0across=A0this.

v>
I have a mod_perl instance that produces output just as it should (c=
hecked in the logs and I even written the output to file just to have an ex=
tra check).



The tcpdump also show everything is ok.

<=
/div>
BUT

The content has the following HTML a=
ppended at the end:

<!DOCTYPE HTML PUBLIC =
"-//IETF//DTD HTML 2.0//EN">


<html><head>
<title>200 OK</title> div>
</head><body>
<h1>OK</h1>
<=
div><p>The server encountered an internal error or
misconfi=
guration and was unable to complete


your request.</p>
<p>Please contact the server a=
dministrator,
=A0 rget=3D"_blank">webmaster@host.example.com and inform them of the time =
the error occurred,


and anything you might have done that may have
caused the er=
ror.</p>
<p>More information about this error may be =
available
in the server error log.</p>
<hr>=


<address>Apache/2.2.3 (CentOS) Server at webdavtest Port 81</=
address>
</body></html>

=
So, I've enabled "debug" level logging everywhere and ev=
en enabled diagnostics in the mod_perl script. Nothing strange shows up any=
where.



I even tried to change the return code with=A0return Ap=
ache2::Const::XXX (XXX could be anything) but the return code is ALWAYS 200=
with the above HTML appended to what ever output is sent to the browser. div>


I also noted that the content length header is correct =
for the content sent to the browser and does not include the additional HTM=
L above, but it still confuses the browser.

Any id=
eas?



Environment:

CentOS 5.5 OS wit=
h the following packages:

* httpd-2.2.3-43.el5.cen=
tos.3
*=A0mod_perl-2.0.4-6.el5

In my con=
fig I have the following enabled:



*=A0LogLevel debug
*=A0PerlWarn On
=

Thanks

Nico


--0015175cb1d4926c0804913a5617--

Re: All responses are 200 (server error)

am 27.09.2010 13:09:21 von Peter Janovsky

--Apple-Mail-10-188406666
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

Are you returning the value of 200 within a module you've written? I encoun=
tered a similar issue within a C module specific to valid requests. It was r=
esolved by returning the internal constant OK.=20



On Sep 27, 2010, at 5:27, Nico Coetzee wrote:

> Hi - don't know if anybody else have come across this.
>=20
> I have a mod_perl instance that produces output just as it should (checked=
in the logs and I even written the output to file just to have an extra che=
ck).
>=20
> The tcpdump also show everything is ok.
>=20
> BUT
>=20
> The content has the following HTML appended at the end:
>=20
>
>
> 200 OK
>
>

OK


>

The server encountered an internal error or
> misconfiguration and was unable to complete
> your request.


>

Please contact the server administrator,
> webmaster@host.example.com and inform them of the time the error occurred=
,
> and anything you might have done that may have
> caused the error.


>

More information about this error may be available
> in the server error log.


>

>
Apache/2.2.3 (CentOS) Server at webdavtest Port 81

>
>=20
> So, I've enabled "debug" level logging everywhere and even enabled diagnos=
tics in the mod_perl script. Nothing strange shows up anywhere.
>=20
> I even tried to change the return code with return Apache2::Const::XXX (XX=
X could be anything) but the return code is ALWAYS 200 with the above HTML a=
ppended to what ever output is sent to the browser.
>=20
> I also noted that the content length header is correct for the content sen=
t to the browser and does not include the additional HTML above, but it stil=
l confuses the browser.
>=20
> Any ideas?
>=20
> Environment:
>=20
> CentOS 5.5 OS with the following packages:
>=20
> * httpd-2.2.3-43.el5.centos.3
> * mod_perl-2.0.4-6.el5
>=20
> In my config I have the following enabled:
>=20
> * LogLevel debug
> * PerlWarn On
>=20
> Thanks
>=20
> Nico

--Apple-Mail-10-188406666
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=utf-8

Are you returning the value of 200 within a module you've written?  I encountered a similar issue within a C module specific to valid requests. It was resolved by returning the internal constant OK. 



On Sep 27, 2010, at 5:27, Nico Coetzee <> wrote:

Hi - don't know if anybody else have come across this.

I have a mod_perl instance that produces output just as it should (checked in the logs and I even written the output to file just to have an extra check).



The tcpdump also show everything is ok.

BUT

The content has the following HTML appended at the end:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">


<html><head>
<title>200 OK</title>
</head><body>
<h1>OK</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete


your request.</p>
<p>Please contact the server administrator,
  and inform them of the time the error occurred,


and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>


<address>Apache/2.2.3 (CentOS) Server at webdavtest Port 81</address>
</body></html>

So, I've enabled "debug" level logging everywhere and even enabled diagnostics in the mod_perl script. Nothing strange shows up anywhere.



I even tried to change the return code with return Apache2::Const::XXX (XXX could be anything) but the return code is ALWAYS 200 with the above HTML appended to what ever output is sent to the browser.



I also noted that the content length header is correct for the content sent to the browser and does not include the additional HTML above, but it still confuses the browser.

Any ideas?



Environment:

CentOS 5.5 OS with the following packages:

* httpd-2.2.3-43.el5.centos.3
* mod_perl-2.0.4-6.el5

In my config I have the following enabled:



* LogLevel debug
* PerlWarn On

Thanks

Nico


--Apple-Mail-10-188406666--

Re: All responses are 200 (server error)

am 27.09.2010 17:30:03 von wmrowe

On 9/27/2010 6:09 AM, Peter Janovsky wrote:
> Are you returning the value of 200 within a module you've written? I encountered a
> similar issue within a C module specific to valid requests. It was resolved by returning
> the internal constant OK.

This is a generalized issue of serving ErrorDocuments; if they have a Status/
result code update (such as a backend proxy response or a cgi response), that
will override the original error code. c.f.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49996

So it is not strictly a bug, but you certainly aren't the first to be frustrated
by the behavior; look to the manner you handle ErrorDocuments with, first.

Fwd: All responses are 200 (server error)

am 28.09.2010 06:07:09 von Nico Coetzee

--0015175d67629206b4049149fa3c
Content-Type: text/plain; charset=ISO-8859-1

Oops - seems I didn't include the group on my reply ....

FYI


Here is another test I did (simpler)

-------------------- Apache Config --------------------

PerlModule FNBC::test_statusline
PerlWarn On


SetHandler perl-script
PerlResponseHandler FNBC::test_statusline


-------------------- test_statusline.pm --------------------

package FNBC::test_statusline;
use strict;
use warnings;
use Apache2::Access ();
use Apache2::RequestUtil ();
use Apache2::RequestRec ();
use Apache2::Const -compile => qw( OK );

sub handler {
my $r = shift;
$r->status_line("499 We have been FooBared");
$r->err_headers_out->add( 'X-Testing' => 'True' );
$r->content_type( "text/html" );
my $body = "Testing

It really
does work...

";
$r->set_content_length( length( $body ) );
$r->print( $body );
return Apache2::Const::OK;
}
1;

-------------------- Trace --------------------

GET /test1/sdjakgd HTTP/1.1
Host: webdavtest:81
User-Agent: Links (2.2; Linux 2.6.32-24-generic x86_64; 210x65)
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4,
ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10,
ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, windows-1250,
windows-1251, windows-1252, windows-1256, windows-1257, cp437, cp737, cp850,
cp852, cp866, x-cp866-u, x-mac, x-mac-ce, x-kam-cs, koi8-r, koi8-u, koi8-ru,
TCVN-5712, VISCII, utf-8
Accept-Language: en, *;q=0.1
Connection: Keep-Alive

HTTP/1.1 200 OK
Date: Tue, 28 Sep 2010 06:06:13 GMT
Server: Apache/2.2.3 (CentOS)
X-Testing: True
Content-Length: 92
Connection: close
Content-Type: text/html; charset=UTF-8

Testing

It really does
work...




I really would like to know why I can not set the status line.... I followed
the example from
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html# C_status_line_

Thanks

Nico

--0015175d67629206b4049149fa3c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Oops - seems I didn't include the group on my reply ....

=
FYI


Here is another test =
I did (simpler)

-------------------- Apache Config=A0---=
-----------------


PerlModule FNBC::test_statusline
PerlWar=
n On


<Location /test1>
   SetHandler perl-script div>
   PerlResponseHandler FNBC::test_statusline

</Location>

--------------------=
=A0test_statusline.=
pm=A0--------------------

package FNBC::t=
est_statusline;


use strict;
use warnings;
use Apache2::Access ();<=
/div>
use Apache2::RequestUtil ();
use Apache2::RequestRec ()=
;
use Apache2::Const -compile =3D> qw( OK );



sub handler {
   my $r = shift;
  =A0$=
r->status_line("499 We have been FooBared");
  =
=A0$r->err_headers_out->add( 'X-Testing' =3D> 'True=
9; );
  =A0$r->content_type( "text/html" ); >

  =A0my $body = "<html><head><title>Tes=
ting</title></head><body><h3>It really does work...=
</h3></body></html>";
  =A0$r->set_=
content_length( length( $body ) );


  =A0$r->print( $body );
   return Apache2::Const=
::OK;
}
1;

-------------=
-------=A0Trace --------------------

GET /tes=
t1/sdjakgd HTTP/1.1


Host: webdavtest:81
User-Agent: Links (2.2; Linux 2.6.32-24-=
generic x86_64; 210x65)
Accept: */*
Accept-Encoding: gz=
ip, deflate
Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO=
-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-88=
59-9, ISO-8859-10, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, wind=
ows-1250, windows-1251, windows-1252, windows-1256, windows-1257, cp437, cp=
737, cp850, cp852, cp866, x-cp866-u, x-mac, x-mac-ce, x-kam-cs, koi8-r, koi=
8-u, koi8-ru, TCVN-5712, VISCII, utf-8


Accept-Language: en, *;q=3D0.1
Connection: Keep-Alive
<=
div class=3D"im">

HTTP/1.1 200 OK
Date: =
Tue, 28 Sep 2010 06:06:13 GMT
Server: Apache/2.=
2.3 (CentOS)

X-Testing: True

Content-Length: 92
Connection: close
Content-Type:=
text/html; charset=3DUTF-8

<html><head&g=
t;<title>Testing</title></head><body><h3>It r=
eally does work...</h3></body></html>







Thanks

>Nico


=3D"gmail_quote">


--0015175d67629206b4049149fa3c--

Re: Fwd: All responses are 200 (server error)

am 28.09.2010 06:31:20 von wrowe

Two thoughts...

try status 400 (might be special handling for 4xx unknown)

try r->status instead of/in addition to just r->status_line?

Re: Fwd: All responses are 200 (server error)

am 28.09.2010 07:25:37 von Nico Coetzee

--0016364270d42fac7304914b13a2
Content-Type: text/plain; charset=ISO-8859-1

The status 400 (with $r->status_line) produces the same result "HTTP/1.1 200
OK" and with ($r->status) is creates a "HTTP/1.1 400 Bad Request" (the
custom string gets lost)

The $r->status with a code of 499 produces a "HTTP/1.1 400 Bad Request"



On Tue, Sep 28, 2010 at 6:31 AM, William A. Rowe Jr. wrote:

> Two thoughts...
>
> try status 400 (might be special handling for 4xx unknown)
>
> try r->status instead of/in addition to just r->status_line?
>

--0016364270d42fac7304914b13a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The status 400 (with $r->status_line) produces the same result "HTT=
P/1.1 200 OK" and with ($r->status) is creates a "HTTP/1.1 400=
Bad Request" (the custom string gets lost)


The $r-=
>status with a code of 499 produces a "HTTP/1.1 400 Bad Request&quo=
t;




On Tue, Sep 28, 2010=
at 6:31 AM, William A. Rowe Jr. < owe@rowe-clan.net">wrowe@rowe-clan.net> wrote:
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex;">
Two thoughts...



try status 400 (might be special handling for 4xx unknown)



try r->status instead of/in addition to just r->status_line?




--0016364270d42fac7304914b13a2--

Re: Fwd: All responses are 200 (server error)

am 28.09.2010 08:26:01 von wrowe

On 9/28/2010 12:25 AM, Nico Coetzee wrote:
> The status 400 (with $r->status_line) produces the same result "HTTP/1.1 200 OK" and with
> ($r->status) is creates a "HTTP/1.1 400 Bad Request" (the custom string gets lost)
>
> The $r->status with a code of 499 produces a "HTTP/1.1 400 Bad Request"

Sort of confirms my theory.

Set status to 400 and set status_line to 400 Custom Message, see what happens?

I suspect that 499 simply isn't allowed, which is wrong, but the current
behavior none the less.

Re: Fwd: All responses are 200 (server error)

am 28.09.2010 08:30:58 von Nico Coetzee

--00c09f82cc30ea622d04914bfc07
Content-Type: text/plain; charset=ISO-8859-1

$r->status("400");
$r->status_line("400 Error Baby");

Produces: "HTTP/1.1 400 Error Baby"

And

$r->status("207");
$r->status_line("207 Multi-Status");

Produces: "HTTP/1.1 207 Multi-Status"

So, I recon I will try this now in the main app.

Thanks :-)



On Tue, Sep 28, 2010 at 8:26 AM, William A. Rowe Jr. wrote:

> On 9/28/2010 12:25 AM, Nico Coetzee wrote:
> > The status 400 (with $r->status_line) produces the same result "HTTP/1.1
> 200 OK" and with
> > ($r->status) is creates a "HTTP/1.1 400 Bad Request" (the custom string
> gets lost)
> >
> > The $r->status with a code of 499 produces a "HTTP/1.1 400 Bad Request"
>
> Sort of confirms my theory.
>
> Set status to 400 and set status_line to 400 Custom Message, see what
> happens?
>
> I suspect that 499 simply isn't allowed, which is wrong, but the current
> behavior none the less.
>

--00c09f82cc30ea622d04914bfc07
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

$r->status("400");
$r->status_line(&quo=
t;400 Error Baby");

Produces:=A0"H=
TTP/1.1 400 Error Baby"

And

iv>
$r->status("207");
$r->status_line(&quo=
t;207 Multi-Status");

Produces: "H=
TTP/1.1 207 Multi-Status"

So, I recon I will =
try this now in the main app.


Thanks :-)



class=3D"gmail_quote">On Tue, Sep 28, 2010 at 8:26 AM, William A. Rowe Jr. =
<wrowe@rowe-cla=
n.net> wrote:

x #ccc solid;padding-left:1ex;">
On 9/28/2010 12:25 AM, Ni=
co Coetzee wrote:

> The status 400 (with $r->status_line) produces the same result &quo=
t;HTTP/1.1 200 OK" and with

> ($r->status) is creates a "HTTP/1.1 400 Bad Request" (the=
custom string gets lost)

>

> The $r->status with a code of 499 produces a "HTTP/1.1 400 Bad=
Request"



Sort of confirms my theory.



Set status to 400 and set status_line to 400 Custom Message, see what happe=
ns?



I suspect that 499 simply isn't allowed, which is wrong, but the curren=
t

behavior none the less.




--00c09f82cc30ea622d04914bfc07--

Re: Fwd: All responses are 200 (server error)

am 28.09.2010 08:32:47 von Nico Coetzee

--00c09f93de656a9ee804914c0391
Content-Type: text/plain; charset=ISO-8859-1

and... it works now !!



On Tue, Sep 28, 2010 at 8:30 AM, Nico Coetzee wrote:

> $r->status("400");
> $r->status_line("400 Error Baby");
>
> Produces: "HTTP/1.1 400 Error Baby"
>
> And
>
> $r->status("207");
> $r->status_line("207 Multi-Status");
>
> Produces: "HTTP/1.1 207 Multi-Status"
>
> So, I recon I will try this now in the main app.
>
> Thanks :-)
>
>
>
> On Tue, Sep 28, 2010 at 8:26 AM, William A. Rowe Jr. wrote:
>
>> On 9/28/2010 12:25 AM, Nico Coetzee wrote:
>> > The status 400 (with $r->status_line) produces the same result "HTTP/1.1
>> 200 OK" and with
>> > ($r->status) is creates a "HTTP/1.1 400 Bad Request" (the custom string
>> gets lost)
>> >
>> > The $r->status with a code of 499 produces a "HTTP/1.1 400 Bad Request"
>>
>> Sort of confirms my theory.
>>
>> Set status to 400 and set status_line to 400 Custom Message, see what
>> happens?
>>
>> I suspect that 499 simply isn't allowed, which is wrong, but the current
>> behavior none the less.
>>
>
>

--00c09f93de656a9ee804914c0391
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

and... it works now !!




">On Tue, Sep 28, 2010 at 8:30 AM, Nico Coetzee < ef=3D"mailto:nicc777@gmail.com">nicc777@gmail.com> wrote:
=
x #ccc solid;padding-left:1ex;">
$r->status("400");
$r->status_line(&quo=
t;400 Error Baby");

Produces:=A0"H=
TTP/1.1 400 Error Baby"

And

iv>

$r->status("207");
$r-&g=
t;status_line("207 Multi-Status");

v>
Produces: "HTTP/1.1 207 Multi-Status"


So, I recon I will try this now in the main app.


Thanks :-)
=



On Tue, Sep 28, 201=
0 at 8:26 AM, William A. Rowe Jr. < rowe@rowe-clan.net" target=3D"_blank">wrowe@rowe-clan.net> wr=
ote:


x #ccc solid;padding-left:1ex">
On 9/28/2010 12:25 AM, Nico Coetzee wro=
te:

> The status 400 (with $r->status_line) produces the same result &quo=
t;HTTP/1.1 200 OK" and with

> ($r->status) is creates a "HTTP/1.1 400 Bad Request" (the=
custom string gets lost)

>

> The $r->status with a code of 499 produces a "HTTP/1.1 400 Bad=
Request"



Sort of confirms my theory.



Set status to 400 and set status_line to 400 Custom Message, see what happe=
ns?



I suspect that 499 simply isn't allowed, which is wrong, but the curren=
t

behavior none the less.






--00c09f93de656a9ee804914c0391--

Re: Fwd: All responses are 200 (server error)

am 28.09.2010 08:48:55 von wrowe

On 9/28/2010 1:32 AM, Nico Coetzee wrote:
> and... it works now !!

I'd hit the same bug from CGI some half-decade ago, sorry I didn't
see where the problem was in the first place :(